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ABSTRACT 


This  report  describes  two  sets  of  protocols  implemented  on 
DTNSRDC's  Hyperchannel  based  local  area  network.  The  first  protocol 
set  facilitates  local  area  network  connections  among  arbritrary 
processes  running  on  computers  attached  to  DTNSRDC's  Hyperchannel  net¬ 
work.  The  second  protocol  set  provides  a  mechanism  for  allowing  local 
area  network  hosts  (computers  connected  via  the  Hyperchannel)  to 
store,  retrieve,  and  delete  files  on  other  network  hosts. 


ADMINISTRATIVE  INFORMATION 

The  work  described  in  this  report  was  a  joint  effort  of  the  Sys¬ 
tems  Software  Group  (Code  1892.3)  and  the  Advanced  Systems  Development 
Group  (Code  189.2)  of  the  Computation,  Mathematics  and  Logistics 
Department,  David  W.  Taylor  Naval  Ship  Research  and  Development  Center 
under  sponsorship  of  the  DTNSRDC  Computer  Center  (Code  189) . 
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1.  Introduction 


The  Computation,  Mathematics,  and  Logistics  Department  (CMLD)  at 
the  David  Taylor  Naval  Ship  Research  and  Development  Center  (DTNSRDC) 
operates  a  variety  of  digital  computer  systems  ranging  in  size  from 
small  minicomputers,  such  as  the  PDP  11/34,  to  larger  general  purpose 
mainframes  such  as  the  CDC  Cyber  170-750.  These  systems  support  a 
diverse  workload  in  the  areas  of  engineering  and  scientific  research 
projects,  management  and  financial  record  keeping,  and  office  automa¬ 
tion  systems.  No  single  system  available  in  the  Department  can  pro¬ 
vide  all  the  services  required  by  the  user  community.  At  the  same 
time  many  of  the  applications  operational  on  a  particular  system 
require  resources  that  are  available  only  on  one  of  the  other  proces¬ 
sors.  The  use  of  online  data  storage  devices  is  a  prime  example  of 
this  problem. 

The  Department  has  acquired  a  large  Mass  Storage  Facility  (MSF) 
from  Control  Data  Corporation  (CDC)  which  serves  the  users  of  the 
existing  CDC  computer  systems.  At  the  same  time  the  Department  is 
operating  two  VAX  11/780-UNIX  based  office  automation  systems  which 
are  suffering  from  a  lack  of  online  storage  space.  Access  to  the  MSF 
has  been  made  available  to  foreign  systems  in  general,  and  to  the  two 
VAX's  in  particular  as  a  back-end  data  storage  system.  Access  to  the 
MSF  has  been  achieved  using  Network  Systems  Corporation's  Hyperchannel 
as  the  transport  medium. 

To  support  this  effort  two  protocols  were  developed  and  are 
described  here.  The  first  protocol  facilitates  the  control  of  network 
connections  thereby  allowing  arbitrary  processes  on  the  network  to 
inter-communicate.  The  second  protocol  provides  for  storing,  retriev¬ 
ing,  deleting,  and  tracking  files  on  remote  network  hosts  via  a  net¬ 
work  connection. 

2.  Network  Connection  Protocol  (NCP) 

2.1.  General  Description 

>  The  base  protocol  implemented  on  the  Hyperchannel  is  a  general 
purpose  network  connection  management  protocol.  The  network  connec¬ 
tion  protocol  (NCP)  is  intended  to  allow  any  network  host  to  support 
up  to  255  simultaneous  logical  connections  between  itself  and  remote 
hosts.  This  protocol  makes  no  specific  provisions  to  ensure  data 
integrity  or  flow  control.  Instead,  the  Hyperchannel  hardware  is 
relied  upon  to  provide  these  services.  In  most  cases  this  will  be 
sufficient.-.  However,  where  it  is  not,  application  level  protocols 
must  be  invoxbd^to  handle  these  services  on  a  case  by  case  basis. 

>  ~ .  ■  •>.  '  f 

The  NCP  relies  on  the  concept  of  a  "logical  connection."  A  logi¬ 
cal  connection  is  a  means  of  identifying  a  "conversation"  between  two 
logical  processes  residing  on  hosts  on  the  network.  Each  end  of  a 
logical  connection  is  identified  by  the  hardware  address  of  the  local 
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Hyperchannel  adapter,  the  Hyperchannel  adapter  port  number  to  which 
the  local  host  computer  is  attached  ("0"  for  single  port  adapters), 
and  a  "link  number"  assigned  by  the  local  host's  connection  management 
(NCP)  routines  when  the  logical  connection  is  established. 
Represented  symbolically,  a  connection-end  identifier  consists  of  five 
hexadecimal  digits  of  the  form  HHPLL  where  HH  is  the  Adapter's 
thumbwheel  selectable  hardware  address,  P  is  the  port  number,  and  LL 
is  the  link  number.  The  complete  logical  connection  is  uniquely  iden¬ 
tified  by  the  pair  of  connection-end  identifiers. 

For  example,  if  two  hosts  are  connected  to  the  network  via  Hyper¬ 
channel  adapters  with  hardware  addresses  11  and  22,  respectively,  and 
through  adapter  ports  0  and  1,  respectively,  the  connection-end  iden¬ 
tifiers  for  the  first  host  will  be  of  the  form  llOxx  (where  xx  is  the 
locally  assigned  link  number  for  a  given  connection).  Similarly, 
221yy  will  be  the  form  of  the  second  host's  connection-end  identif¬ 
iers.  Now  if,  for  a  particular  connection  between  the  two  hosts,  the 
first  host  assigned  link  number  6,  and  the  second  host  assigned  link 
number  A,  then  the  complete  logical  connection  is  identified  by  the 
combination  of  the  two  connection  end  identifiers,  viz.  11006/2210A. 
Note  that  each  host  is  free  to  assign  a  link  number  to  each  of  its 
connection  ends  regardless  of  any  link  number  assignments  by  other 
hosts.  Each  message  which  traverses  the  network  contains  the  complete 
logical  connection  identifier  (hardware  addresses  and  link  numbers)  to 
unambiguously  denote  the  sending  and  receiving  processes. 

Link  number  zero  is  reserved  by  each  host's  NCP  process  for 
exchange  of  the  connection  management  protocol.  This  link  is  used  to 
establish  and  di s-es tab  1 i sh  other  links,  or  to  reject  attempts  by 
other  hosts  to  establish  links  when  it  is  desirable  or  necessary  to  do 
this . 


2.2.  NCP  Functions  and  Formats 

This  section  details  the  link  0  (connection  management)  protocol 
functions  and  format  as  implemented  on  the  Hyperchannel  network.  Note 
that  each  connection  management  protocol  message  is  sent  as  a  Hyper¬ 
channel  "message  proper"  with  no  "associated  data."  Moreover,  the 
first  eight  bytes  (0-7)  of  each  message  have  specific  meaning  to  the 
Hyperchannel  Adapter  hardware.  The  reader  is  referred  to  Network  Sys¬ 
tems  Corporation's  publication  Hyperchannel  -  Systems  Description 
Manual  (publication  number  A01-0000-02)  for  an  understanding  of  these 
terms  and  fields. 

In  the  following  descriptions  all  values  for  field  offsets  and 
parameter  values  are  given  as  hexadecimal  constants  unless  specifi¬ 
cally  stated  otherwise. 


A 


2.2.1.  Open  (OPN)  Function 


This  function  is  issued  by  a  host  to  open  a  logical  connection 
and  "echoed"  by  the  receiver  to  signal  its  acceptance  of  the  connec¬ 
tion  request.  If  the  request  cannot  be  honored,  the  RJT  function  will 
be  sent  in  reply.  When  a  network  host  initially  requests  a  connection 
to  a  remote  host,  it  assigns  a  logical  link  number  for  its  end  of  the 
connection  to  be  established  and  places  this  link  number  in  parameter 
field  pi.  It  also  clears  parameter  field  p2.  The  receiver  of  such  a 
function  completes  the  connection  by  assigning  a  logical  link  number 
for  its  end  of  the  connection.  It  places  this  in  field  pi,  the 
initiator's  link  number  in  field  p2,  and  sends  a  confirming  OPN  mes¬ 
sage.  Figure  2-1  describes  the  format  of  the  OPN  message  block. 
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trk  -  trunk  selection  bits 

ctl  -  control  bits 

acc  -  access  code 

rad  -  receiver's  adapter  address 

rpn  -  receiver's  adapter  port  number  (zero  if  single  port  adapter) 
sad  -  sender's  adapter  address 

spn  -  sender's  adapter  port  number  (zero  if  single  port  adapter) 
op  -  operation  code  -  OPN  function  (01) 
sin  -  sender's  link  number  (always  zero  for  NCP  messages) 
rln  -  receiver's  link  number  (always  zero  for  NCP  messages) 
pi  -  sender's  link  number  to  be  used  for  the  newly  established  con¬ 
nection 

p2  -  receiver's  link  number  to  be  used  for  the  newly  established 
connection  (zero  for  requesting  OPN,  initiator's  link  number 
for  confirming  OPN) 

pid  -  name  of  the  server  process  to  which  this  connection  attempt  is 
directed 


Figure  2~1  -  NCP  Open  (OPN)  Message  Format 


2.2.2.  Close  (CLS)  Function 


This  function  is  issued  by  a  host  to  close  a  logical  connection. 
The  initiator  of  the  close  inserts  the  link  number  for  his 
connection-end  in  parameter  pi  and  the  remote  host's  link  number  for 
the  remote  connection-end  in  parameter  p2.  The  receiving  system  ack¬ 
nowledges  the  request  by  transmitting  an  answering  CLS  message  after 
reversing  pi  and  p2.  Note  that  this  scheme  allows  each  host  to  simul¬ 
taneously  and  unilaterally  initiate  a  close  on  the  same  logical  con¬ 
nection. 


trk  |  ctl  |  acc  (  acc  [  rad  i  rpn  j  sad 


n/u  |  op 


trunk  selection  bits 
control  bits 
access  code 

receiver's  adapter  address 
receiver's  adapter  port  number 
sender's  adapter  address 
sender's  adapter  port  number 
operation  code  -  CLS  function  (02) 

sender's  link  number  (always  zero  for  NCP  messages) 
receiver's  link  number  (always  zero  for  NCP  messages) 
sender's  link  number  of  the  connection  to  be  closed 
receiver's  link  number  of  the  connection  to  be  closed 


Figure  2-2  -  NCP  Close  (CLS)  Message  Format 


2.2.3.  Reject  (RJT)  Function 

This  function  is  used  to  refuse  OPN  requests  or  to  reject  in¬ 
formed  link  zero  messages  such  as  illegal  op  code,  etc.  It  requires 
no  acknowledgment. 

0123456789 


|  trk  |  ctl  1  acc  |  acc  1  rad  |  rpn  J  sad  |  spn  |  0  |  op  | 


A  B  C  D 


|  sin  |  rln  [  rc  J  pi  | 


trk  -  trunk  selection  bits 
ctl  -  control  bits 
acc  -  access  code 
rad  -  receiver's  adaptor  address 
rpn  -  receiver's  port  number 
sad  -  sender's  adapter  address 
spn  -  sender's  port  number 
op  -  operation  code  -  RJT  function  (03) 
sin  -  sender's  link  number  (always  zero), 
rln  -  receiver’s  link  number  (always  zero), 
rc  -  reason  code  for  connection  rejection 
01  -  illegal  op  code 
02  -  invalid  link 
03  -  no  links  available 

pi  -  if  rc  *  3,  link  number  on  which  user  tried  to  open  a  connection. 


Figure  2-3  -  NCP  Reject  (RJT)  Message  Format 
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3.  File  Transfer  Protocol  (FTP) 


3.1.  General  Description 

The  objective  of  this  protocol  is  to  permit  network  hosts  to  access 
the  file  system  of  other  hosts  on  the  network  via  a  Hyperchannel  con¬ 
nection.  Each  host  with  a  user  FTP  process  can  store,  retrieve, 
delete,  or  list  directory  information  from  the  file  system  of  any 
other  host  with  a  server  FTP  process. 

This  protocol  consists  of  eight  functions  used  to  control  the 
transfer  of  files  or  directory  information  between  the  two  FTP 
processes.  All  connections  are  initiated  by  the  user  FTP  process  and 
maintained  until  closed  by  the  user  FTP  process. 

To  facilitate  the  efficient  use  of  the  MSF  cartridge  system  and  to 
provide  support  for  the  transfer  of  CDC  system  binary  images  and  pro¬ 
gram  libraries,  the  concepts  of  system  End  of  Record  (EOR) ,  End  of 
File  (EOF),  and  End  of  Information  (EOI)  are  provided.  These  concepts 
provide  a  mechanism  for  partitioning  a  data  set  into  discrete  subsets. 
Using  these  structures  a  remote  system  can  consolidate  its  files  to 
make  more  efficient  and  cost  effective  use  of  the  MSF  allocation 
mechanisms.  This  feature  can  also  serve  to  minimize  the  quantity  of 
data  moved  over  the  network  when  it  is  desired  to  retrieve  a  sub-file 
rather  than  an  entire  data  set.  For  non-CDC  systems  the  implementa¬ 
tion  of  these  data  set  partitioning  mechanisms  will  be  system  depen¬ 
dent  . 

The  protocol  relies  on  the  data  validation  performed  by  the  Hyper¬ 
channel  hardware  to  ensure  file  integrity.  No  checksumming  is  per¬ 
formed  in  the  software.  No  mechanism  is  provided  in  the  protocol  for 
flow  control.  It  is  assumed  that  the  status  returns  from  the  Hyper¬ 
channel  hardware  and  their  data  buffering  capabilities  are  sufficient 
to  recover  data  overrun  conditions.  Because  the  connection  between 
remote  systems  is  full  duplex,  it  is  incumbent  on  both  the  sending  and 
receiving  systems  to  monitor  the  Hyperchannel  for  incoming  messages. 

Basic  protocol  information  is  passed  as  part  of  the  Hyperchannel 
message  proper.  Byte  9  of  this  message  always  contains  one  of  the 
eight  prot ocol -def ined  function  codes.  Bulk  data  associated  with  each 
FTP  message  block  is  sent  as  an  associated  data  block.  The  protocol 
places  no  restriction  other  than  an  absolute  maximum  of  20,000  bytes 
on  the  length  of  each  associated  data  block.  As  a  result  it  is  the 
responsibility  of  the  user  and  server  FTP  processes  to  cooperate  on 
block  sizes  such  that  differences  in  word  size  and  memory  addressabil¬ 
ity  between  hosts  of  different  hardware  architecture  do  not  corrupt 
the  integrity  of  associated  data. 

3.2.  FTP  Function  Descriptions 

The  f  o! lowing  pages  detail  the  format  and  content  of  the  FTP  proto¬ 
col  messages.  All  relative  block  offsets  and  parameter  values  are 
given  as  hexadecimal  constants  unless  explicitly  stated  otherwise. 
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3.2.1.  FTP  Data  Function  (DAT) 

This  function  is  used  to  transfer  file  or  directory  data  between 
the  server  and  user  FTP  process.  No  response  is  required.  Once  ini¬ 
tiated,  the  transfer  of  FTP  data  blocks  will  be  repeated  until  the 
logical  end  of  information  is  reached.  The  end  of  information  is 
always  signaled  by  a  DAT  message  with  the  EOI  flag  set.  This  message 
may  or  may  not  have  associated  data.  If  the  receiver  of  the  data 
wishes  to  interrupt  the  transfer  for  some  reason,  he  should  do  so  by 
transmitting  an  FTP  negative  acknowledgment  message  with  an . appreci¬ 
ate  reason  code.  The  NAK  will  abort  any  additional  processing  for  the 
FTP  function  in  progress.  Figure  3~1  details  the  format  and  content 
of  a  DAT  message  block. 


trk  j  ctl  j  acc  |  acc  j  rad  |  rpn  ]  sad  |  spn 


sin  |  rln  |  fig 


trunk  selection  bits 
control  bits 
access  code 

receiver's  adapter  address 

receiver's  port  number 

sender's  adapter  address 

sender's  port  number 

operation  code  -  DAT  function  (10) 

sender's  link  number 

receiver's  link  number 

file  structure  flag  bits 

01  -  End  of  record  (EOR) 

02  -  End  of  file  (EOF) 

04  -  End  of  information  (EOI) 


Figure  3~1  -  FTP  Data  Message  Format 


3.2.2.  Positive  Acknowledgment  Function  (ACK) 


This  function  is  used  to  signal  a  positive  acknowledgment  of  FTP 
requests.  It  is  sent  only  by  the  server  FTP  process.  Figure  3~2 
details  the  format  and  content  of  an  ACK  message  block. 


0123456789 


|  trk  |  ctl  |  acc  j  acc  1  rad  !  rpn  {  sad  |  spn  |  0  j  op 


A  B 


|  sin  |  rln  J 


trk  -  trunk  selection  bits 
ctl  -  control  bits 
acc  -  access  code 
rad  -  receiver's  adapter  address 
rpn  ~  receiver's  port  number 
sad  -  sender's  adapter  address 
spn  -  sender's  port  number 
op  -  operation  code  -  ACK  function  (11) 
sin  -  sender's  link  number 
rln  -  receiver's  link  number 


3.2.3.  Negative  Acknowledgment  Function  (NAK) 

This  function  is  issued  by  the  server  FTP  process  in  response  to  a 
request  from  a  user  FTP  process  that  cannot  be  honored  or  by  either 
the  server  or  user  FTP  process  to  abort  a  data  transfer.  The  rc  field 
contains  an  error  code  for  the  error  condition.  Bytes  F  -  3F  contain 
the  ASCII  text  of  an  appropriate  error  message.  Figure  3-3  details 
the  format  and  content  of  a  NAK  message  block. 


0123456789 


trk  |  ctl  !  acc  |  acc  |  rad |  rpn  |  sad  |  spn  |  0  j  op  | 


A  B  C  D  E  F  10  3F 

sin  |  rln  j  rc  j  0  |  0  |  txt  |  txt  j  .  |  0  | 


trk  -  trunk  selection  bits 
ctl  -  control  bits 
acc  ~  access  code 
rad  -  receiver's  adapter  address 
rpn  -  receiver's  port  number 
sad  -  sender's  adapter  address 
spn  -  sender's  port  number 
op  -  operation  code  NAK  function  (12). 
sin  -  sender's  link  number 
rln  -  receiver's  link  number 
rc  -  reason  code  (hexadecimal) . 

01  -  illegal  function 
02  -  invalid  user  number/password 
03  -  File  access  error 
04  -  I/O  error 

05  -  FTP  protocol  sequence  error 
06  -  File  busy  (retry  later) 

07  -  File  being  staged  from  secondary  storage  to  disk 
(retry  later) . 

txt  -  ASCII  text  describing  the  error  condition.  The  text  is  terminat¬ 
ed  by  a  zero  byte  (NUL) . 


Figure  3-3  -  FTP  Negative  Acknowledgment  Message  Format 
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3. 2. A.  User  Validation  Function  (USR) 

This  function  must  be  the  first  FTP  function  issued  by  a  user  FTP 
process  after  establishing  a  network  connection.  The  server  FTP  pro¬ 
cess  will  respond  with  positive  acknowledgment  (ACK)  if  the  user 
number/password  is  successfully  validated.  If  validation  fails,  the 
server  FTP  process  will  send  negative  acknowledgment  (NAK) .  This  func¬ 
tion  may  be  issued  as  appropriate  after  initial  validation  to  switch 
to  new  user  numbers  for  processing  of  additional  files.  Figure  3-A 
details  the  format  and  content  of  a  USR  message  block. 


1 

2 

3 

A 

5 

6 

7 

8 

9 

!  trk  ; 

ctl  ! 

acc  | 

acc  ; 

rad  ! 

rpn  | 

sad  | 

spn  | 

o  ! 

op  | 

A 

B 

C 

D 

E 

F 

10 

11 

12 

13 

!  sin  | 

rln  | 

o  : 

o  ! 

o  ! 

o  ! 

o  ! 

0  ! 

mm 

o  ! 

14 

15 

16 

17 

18 

19 

1A 

IB 

1C 

ID 

|  uid  | 

uid  | 

uid  i 

uid  | 

uid  | 

uid  | 

!  uid  | 

0  ! 

o  ! 

1  0  1 

1  V  ( 

IE 

IF 

20 

21 

22 

23 

2A 

25 

26 

27 

!  P«d  ! 

pwd  | 

pwd  ! 

pwd  | 

pwd  ! 

pwd 

!  pwd  ! 

o  ! 

0 

1  0  1 

1  u  1 

trk  -  trunk  selection  bits 
ctl  -  control  bits 
acc  _  access  code 
rad  ~  receiver's  adapter  address 
rpn  -  receiver's  port  number 
sad  -  sender's  adapter  address 
spn  -  sender's  port  number 
op  -  operation  code  -  USR  function  (13). 
sin  -  sender's  link  number 
rln  -  receiver's  link  number 

uid  -  user  identifier  (ASCII),  left  adjusted  with  zero  fill. 

pwd  -  user’s  account  password  (ASCII),  left  adjusted  with  zero  fill. 


Figure  3-A  -  FTP  User  Message  Format 


3.2.5.  Retrieve  a  Remote  Data  Set  (GET) 


This  function  is  used  to  request  a  copy  of  a  remote  data  set.  The 
file  specification  string  for  the  data  set  accompanies  the  message  as 
an  associated  data  block.  The  file  specification  consists  of  an  ASCII 
text  string  terminated  with  a  zero  (NUL)  character  and  is  host  depen¬ 
dent.  The  server  FTP  process  is  responsible  for  parsing  the  file 
specification.  Legal  responses  are  NAK  and  ACK.  If  the  request  is 
acknowledged,  the  server  FTP  process  will  begin  the  data  transfer 
immediately  after  the  ACK.  Figure  3-5  details  the  format  arid  content 
of  a  GET  message  block. 


0 

1 

2 

3 

4  5 

6 

7 

8 

9 

!  trk  ! 

ctl  | 

acc  | 

acc  | 

rad  |  rpn  | 

sad  ! 

spn  | 

o  ! 

op  | 

A 

B 

C 

D 

IE 

IF 

20 

21 

i  sin  ! 

rln  | 

fty  ! 

o  ! 

1 

•  •  •  | 

fno  | 

fno  | 

fct  | 

fct  | 

1E 

IF 

20 

21 

trk  -  trunk  selection  bits 

ctl  -  control  bits 

acc  -  access  code 

rad  -  receiver's  adapter  address 

rpn  -  receiver's  port  number 

sad  -  sender's  adapter  address 

spn  -  sender's  port  number 

n/u  -  not  used 

op  -  operation  code  -  GET  function  (14) . 
sin  -  sender's  link  number 
rln  -  receiver’s  link  number 
fty  -  File  type 

0  -  ASCII  text 

1  -  CDC  display  code  text 

2  -  Binary  data 

fno  -  relative  file  offset  of  first  file  to  be  retrieved 
fct  -  number  of  files  to  be  retrieved. 


Figure  3-5  -  FTP  Get  Message  Format 


3.2.6.  Store  a  Data  Set  Remotely  (PUT) 


This  function  is  used  to  request  that  a  data  set  be  stored  on  the 
remote  system.  The  file  specification  to  be  used  in  creating  the  file 
on  the  remote  host  is  passed  in  an  associated  data  block.  The  file 
specification  is  an  ASCII  text  string  terminated  with  a  zero  (NL'L) 
character  and  is  host  dependent.  It  is  the  respons ibi li ty  of  the 
server  FTP  process  to  parse  the  file  specification.  Valid  responses 
are  NAK  and  ACK.  Upon  receipt  of  an  ACK  the  requesting  host  may  begin 
the  data  transfer.  Figure  3-6  details  the  format  and  content  of  a  PUT 
message  block. 


0123456789 
!  trk  |  ctl  |  acc  |  acc  \  rad  S  rpn  !  sad  |  spn  j  0  |  op 


ABC 


|  sin  |  rln  |  fty  ] 


trk  -  trunk  selection  bits 
ctl  -  control  bits 
acc  '  access  code 
rad  -  receiver's  adaptor  address 
rpn  -  receiver’s  port  number 
sad  -  sender's  adapter  address 
spn  -  sender's  port  number 
op  -  operation  code  -  PUT  function  (15). 
sin  -  sender's  link  number 
rln  -  receiver's  link  number 
fty  -  File  type 

0  -  ASCII  text 

1  -  CDC  display  code  text 

2  -  Binary  data 


Figure  3~6  -  FTP  Put  Message  Format 


3.2.8.  Retrieve  Remote  Directory  Information  (DIR) 


This  function  is  issued  to  request  directory  information  from  a 
remote  host’s  file  system.  A  directory  specif ication  may  accompany 
the  request  in  an  associated  data  block.  The  directory  specification 
consists  of  an  ASCII  text  string  terminated  with  a  zero  (NUL)  charac¬ 
ter  and  is  host  dependent.  It  is  the  responsibility  of  the  receiving 
server  FTP  process  to  parse  the  string.  The  remote  system  will 
respond  with  positive  acknowledgment  (ACK)  if  the  directory  is  suc¬ 
cessfully  accessed  and  follow  immediately  with  data  (DAT)  blocks  con¬ 
taining  the  directory  data.  Directory  data  consist  of  one  or  more 
ASCII  text  lines,  formatted  by  the  serving  FTP  process,  and  terminated 
with  a  zero  (NUL)  character.  If  directory  access  fails  the  server  FTP 
process  will  send  negative  acknowledgment  (NAK) .  Figure  3~8  details 
the  format  and  content  of  a  DIR  message  block. 


0 

1 

2 

3 

4 

5 

trk  j 

!  eti  J 

!  acc  J 

!  acc 

!  rad 

!  rpn  | 

6 

7 

8 

9 

sad  | 

spn  | 

o  ! 

op  | 

Thi»  appendix  provides  examples  of  common  NCP  protocol  exchanges. 
In  the  interest  of  brevity,  the  first  9  bytes  of  each  message  are 
ommitted  since  they  are  dictated  by  the  hardware  and  are  not  a  part  of 
the  NCP  protocol.  Each  message  description  starts  with  the  NCP  opera¬ 
tion  code,  given  as  a  mnemonic,  and  is  followed  by  a  list  parameters, 
separated  by  commas  (,)  which  correspond  positionally  to  the  fields 
described  in  Section  2  of  this  document.  Fields  which  contain  charac¬ 
ter  data  are  represented  as  character  strings  enclosed  in  quotes  (") . 
The  entire  message  description  is  bracketed  by  the  character*  <  and  ». 


Example  1  -  Connection  open 

Host  A  Host  B 

<OPN,0,0, 1,0,"SRVRFTP"> 

<0PN,0,0,2, 1> 


Example  2  -  Connection  refusal  for  insufficient  links 
Host  A  Host  B 

<OPN ,  0, 0, 1 , 0 ,  "SRVRFTP''> 

<RJT,0,0,3,1> 


Example  3  -  Connection  refusal  for  process  unknown  or  unavailable 


Host  A 

<0PN, 0, 0, 1,0, "BADPID"> 


Host  B 

<RJT,0,0,3,1> 


Example  4  -  Connection  close  exchange 

Host  A  Host  B 

<CLS,0,0, 1 ,2> 

<CLS,0,0,2,1> 


,s  blank 
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This  appendix  provides  examples  of  valid  FTP.  protocol  exchanges. 
In  the  interest  of  brevity,  the  first  9  bytes  of  each  message  are 
ommitted  since  they  are  dictated  by  the  hardware  and  are  not  a  part  of 
the  NCP  protocol.  Each  description  presumes  the  prior  establishment 
of  logical  connection  via  the  appropriate  NCP  protocol  exchange. 
Each  message  description  starts  with  the  FTP  operation  code,  given  as 
a  mnemonic,  and  is  followed  by  a  list  of  parameters,  separated  by  com¬ 
mas  (,)  which  correspond  positionally  to  the  fields  described  in  Sec¬ 
tion  3  of  this  document.  Fields  which  contain  character  data  are 
represented  as  character  strings  enclosed  in  quotes  (") .  The  entire 
message  description  is  bracketed  by  the  characters  <  and  >.  Associ¬ 
ated  data  accompanying  the  message  is  represented  as  a  string  of  text 
enclosed  in  the  characters  [  and  3,  and  appended  to  the  end  of  the 
message  description. 


Example  1  -  User  validation 

Host  A  Host  B 

<USR ,1,2, "userid" , "paswrd"> 

<ACK,2,1> 


Example  2  -  User  validation  failure 

Host  A  Host  B 

<USR ,1,2, "userid" , "paswrd"> 

<NAK, 2, 1,2, "Invalid  user"> 


Example  A  -  Store  file  remotely 

Host  A  Host  B 

<PUT, 1,2, 1 >  [ANYFILE/AC-123A567890] 

<ACK,2, 1> 

<DAT,1,2,0>  [First  file  block] 

<DAT,1,2,0>  [Second  file  block] 


<DAT,1,2,A>  [Last  file  block] 


Example  5  -  Delete  remote  file. 
Host  A 

<PUR,1,2>  [ANYF1LE/UN-HIS] 


Host  B 


<ACK,2,1> 


Example  6  -  Get  remote  directory  information 

Host  A  Host  B 


<DIR,1,2>  [/ETC/BIN/*] 


<ACK,2, 1> 
<DAT,2, 1 ,0> 
<DAT , 2 , 1 , 0> 
<DAT , 2 , 1 , A> 


[First  directory  block] 
[Second  directory  block] 
[Last  directory  block] 


•  , 


2A 


INITIAL  DISTRIBUTION 
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